The standard behavior of a SDN network controller implies the reactive configuration of forwarding rules for any new flow that does not match any existing entry in a flow table. The setup process for any new rule starts once a new packet arrives at a computer networking device such as a switch in case said switch does not contain any specific entry in the flow table. In that case, the switch sends a flow request to the SDN controller which analyses the packet for defining an applicable rule that is finally configured in the switch. The rules consist of an action (e.g. forward to a certain port, drop, send to the network controller, etc.) determined by a match or arbitrary bits in the packet header (e.g., MAC address, IP address, VLAN tag, TCP port, etc.).
The performance of this process depends on the switch and the SDN controller resources (CPU, memory, etc.) and can lead to a serious scalability issue, since the potential number of request to the network controller for a new rule is directly proportional to the number of distinct active flows in the communication network.
The SDN paradigm was originally conceived for efficient communication between virtual (or physical) machines residing in datacenter environments. In this environment the applications hosted in different devices communicates with each other to provide a certain service.
Nowadays the SDN concept is progressively gaining momentum and its application to conventional communication networks is envisaged. It is then needed to solve the potential scalability issues that central elements in a communication network could suffer (in this case, a SDN controller) due to the massive usage of the communication network by the end users.
Apart from that, Domain Name Service (DNS) is a standardized protocol and one of the basic services needed in today's Internet. Apart from name resolution service, DNS it has been extended several uses. One is the DNS-SD or DNS Service discovery [1] that was defined with the aim of simplified the network clients to discover and user offered service by the network like, browsing or printing. Another common use is a DNS-based request routing by Content Delivery Networks (CDNs) that resolve a different IP address of the CDN Server based in its own criteria. One typical scenario is using IP source geolocation to resolve different IP address of the content Server, trying to offer contents physically as closed as possible to the source resolving IP address.
Security Services based in DNS is another common practice. Fighting against spam and malware through a DNS-based Blackhole List (DNSBL) is a common practice.
As mentioned before, the reactive configuration of the switch by the network controller is the common behavior of an SDN network (as can be seen, for instance, in the OpenFlow specification [2]), which can lead to serious scalability issues. An example of a solution evolved from the OpenFlow specification is the OpenDayLight project [3]. It provides a REST API for its controller platform which may configure the DNS servers for a controller node. Another example of an evolved solution is the HP Sentinel [4] that only uses the SDN technology to receive DNS traffic and allow or not said DNS traffic by progressing the DNS request based on local rules. Therefore, said solution only allows progressing or not a user request after having compared it with a predefined list of rules.
On another hand, proactive configurations are implemented by network administrators directly specifying in the network controller flow policies without an actual knowledge of which flows will be created by the end user, then being generic, and not based on the real traffic that will pass through the network.
Apart from that, rules can change over time according to the network needs, and the memory in the switches is limited, so no fine-grain rules can be pre-configured for all the potential flows in the network.
Finally, in a telecommunication environment is more than probable that more than one network domain (sub-network) should be passed through the flow for setting and end-to-end communication. Then it is needed to establish a communication between SDN controllers across the entire network in order to preconfigure the flow rule in advance end-to-end.